Service Level Executable Environment for Integrated PSTN and IP Networks and Call Processing Language Therefor

ABSTRACT

A service level executable environment (SLEE) in a telecommunications network linking a PSTN and a packet (e.g., IP) network is provided. The SLEE includes a scripting language, a compiler adapted to compile scripts written with said scripting language into executables, and a plurality of dynamically loaded shared libraries, wherein the dynamically loaded shared libraries are distributed over the IP network and executables can utilize dynamically loaded shared libraries from different locations in the IP network.

This application claims the benefit of provisional applications U.S.Ser. No. 60/182,111 filed Feb. 11, 2000.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates broadly to telecommunications. More particularly,this invention relates to a switching infrastructure and developerenvironment for telecommunication applications.

2. State of the Art

For much of the history of the telecommunications industry, telephonecalls have been connected primarily via the public switch telephonenetwork (PSTN), a point-to-point telecommunications network. The PSTNincludes end office (EO) and access tandem (AT) switches. The EOswitches connect a local carrier to a subscriber (a party capable ofmaking or receiving a call), and the AT switches connect local carriersand other intermediary AT switches together. In the PSTN, a path(circuit) is defined between the calling party and the called partythrough the EO and AT switches, and the call is connected over thispath. For a long time, signaling associated with the call (e.g.,information about the route through various switches to the calledparty) and the call content (e.g., analog voice signals) were sent overthe same path in the network.

The PSTN was designed to handle voice calls having an average durationof five minutes. Due to a change in calling patterns, in which theaverage call has become longer, the PSTN network has become quitecongested. The reason for the change in calling patterns is, at least inpart, a result of the popularity of the Internet and an associatedincreased data traffic from modem use. Modem calls are typicallyrelatively longer than voice calls, averaging thirty minutes induration.

As a partial solution to the congestion, the SS7 (signaling system 7)system was deployed. In SS7, the signaling for setting up a path for thecall is sent “out-of-band” (over a discrete network), and the call isthen connected via a path through the legacy PSTN. While this removesthe signaling traffic from the PSTN network switches, even this systemdoes not satisfactorily relieve the PSTN network congestion.

In the 1980's, long distance telecommunication was deregulated. New longdistance companies, such as MCI and Sprint, among others, were grantedequal access to end-office (EO) switches at the local exchange carriercentral office in order to compete directly with AT&T by installingtheir own access tandem (AT) switches and their own long distancenetwork.

With the Telecommunications Act of 1996, competition was opened forlocal telephone service, giving rise to competitive local exchangecarriers (CLECs). CLECs were permitted equal access to the AT switchesof the long distance companies, and local exchanges needed to make spaceavailable in their central offices for a competitor's EO switch. Assuch, the regulatory guidelines that governed the separation offunctionalities which previously existed between an AT exchange (switch)and an equal access EO exchange have for the most part diminished.Therefore, switching systems residing in the local exchange todaytypically have both end-office and access tandem functionality; hence,the term EO/AT.

Given the increase in competition created by deregulation, the cost tothe consumer to make a voice call, both local and long distance, hasdecreased. Consequently, the per call profit to the call provider hasalso decreased. As such, call providers have been eager to offerprofit-making value-added enhanced services above and beyond Class 5services such as caller-ID, three-way calling, call waiting, etc.Originally, these services were implemented on the EO switches; atypical implementation occurred on the EO switch of the called party.The implementation was “hard coded” into the switch, and a call providerwas tied to the EO-switch vendor for services.

It was therefore desired to implement enhanced services in a mannerwhich was both effective and did not rely on the switch vendor forservices. To meet this need, the Advanced Intelligent Network (AIN) hasbeen implemented in some areas. The AIN comprises service control pointsin the SS7 network and operates to move call services away from thetraffic switches to de-couple service logic from the switching functionand provide an enhanced system of service distribution and third partyservice suppliers. However, the AIN system has been hindered by SS7interoperability issues with respect to different Tier 1 InternationalCarriers and also due to vendor-specific implementations. That is, animplementation of the AIN system is confined to a particular geographicarea and/or vendor. For example, in Europe there are multiple carriers,each using a different and incompatible AIN protocol.

During the 1990's, the Internet grew at a tremendous rate. Traffic overthe Internet is transferred in a uniform manner using Internet Protocol(IP). The IP network therefore has an architecture adapted to providecommunication and services over a single and uniformly compatible systemworldwide. As such, the IP (or other packet) network has been recognizedas a possible substitute for the PSTN.

However, moving from the PSTN system to an IP (or other type of packet)network would require the challenging integration of the IP network withthe legacy PSTN system. This is because any change from the PSTN systemwould necessarily be deployed over time. In addition, the IP network isa packet-based network. This is suitable for viewing web pages on theworld-wide web where timing is not critical. It would be ideal to moveenhanced call services away from the EO/AT switches and make availableand distribute call services in a non-localized manner, similar to themanner in which web pages are made available. Yet, for some callservices latency is critical.

Services are distinguished by class, with Class 5 service functions(e.g., three-way calling) requiring practically immediate implementationupon request and therefore residing onboard the stored program controlswitch (SPCS) in the PSTN. Over the years these embedded servicefunctions have been highly optimized. In fact, it takes only 50-120milliseconds for an SPCS to route a call to its destination from thetime a user goes off-hook and dials the number, inclusive of cyclingthrough a Class 5 feature interaction. This time measurement is referredto as the Class 5 delay budget, and is relatively immovable, as callersexpect immediate response for such services. This benchmark posessignificant challenges to next-generation telecommunication architectureutilizing an IP network.

When referring to “next-generation” architecture, it is presumed thatthe application server (AS) which handles the enhanced services willreside separately from the basic call processes (BCP), or call controlelements, in the network. Where the AS has been decoupled from a switch,interworking between the decoupled AS and the switch is oftenimplemented using the H.323 Initiation Protocol (SIP). However, there isno evidence that a decoupled AS can be used in a loosely decoupledfashion to implement a Class 5 service in a production network. TheClass 5 delay budget imposes an insurmountable barrier to Class 5service distribution. As such, there is a significant difference betweenemulation of a Class 5 service in an offline laboratory, and actuallyreplacing a Class 5 end-office switch delivering primary line telephoneservice to thousands of subscriber lines.

Moreover, once the challenge of integrating the IP and PSTN networks isaccepted, it would be further beneficial to have a programmingenvironment which is adapted to facilitate creation, deployment anddistribution of enhanced services over the integrated network. Servicedistribution operates to relieve network congestion. Moreover, servicedistribution over an IP network reduces the relative high costsassociated with using the PSTN for the implementation of such services.

For purposes of this disclosure, the telecommunications network(s) isoften referred to using the following suggestive abstract terms: themedia transport plane, the signalling and control plane, the applicationservices plane, and the management plane. The media transport planedefines the portion of the network devoted to delivering content fromone point (or multipoints) to another point (or multipoints) in thenetwork. The signalling and control plane is primarily used to set upand tear down connections. The application services plane is the portionof the network used to deliver enhanced services. The management planeis used for buffing, record keeping, provisioning, etc.

Over the last several years, the the efforts of the telecommunicationsindustry to integrate the PSTN with an IP network have been spentlargely in proving out the new voice over packet switching technologieswhich primarily address the media transport plane. To a lesser extent,softswitches, which address the signaling and control plane in the newgeneration network have just come onto the horizon. This adoption cycle,albeit necessary, has continued at the expense of not realizing anysignificant advancements in telecommunications service delivery on alarge scale during the same time period.

SUMMARY OF THE INVENTION

It is therefore an object of the invention to provide a networkarchitecture that can be deployed in stages.

It is another object of the invention to provide a next generationnetwork architecture that is suitable for both the PSTN and IP networks.

It is a further object of the invention to provide an integrated networkthat can deploy multiple types and classes of services.

It is an additional object of the invention to provide an integratednetwork that can implement Class 5 services and meet the Class 5 delaybudget, i.e. a method for implementing service execution functionalentities in a tightly-coupled fashion in relation to a softswitch, suchthat the service execution functional entities operate in a similarfashion to that of an SPCS.

It is also an object of the invention to provide a Class 5 end-officeswitching in a next generation IP network, i.e. a method forimplementing service execution functional entities in a loosely-coupledfashion in relation to a softswitch, such that the service executionfunctional entities operate in a similar fashion to fully detachedApplication Servers on an IP network (such as the Internet).

It is still another object of the invention to provide an integratedsystem capable of distributing enhanced services over the network.

It is still a further object of the invention to provide an integratednetwork in which services are distributed in a manner which permitsservice latency requirements to be met, i.e. a method for providinglocation transparency or abstraction of the distribution of the serviceexecution functional entities from its users.

It is yet another object of the invention to provide a developerenvironment for creating, deploying, and distributing services across anext generation IP network.

It is another object of the invention to provide a method forintercommunication between service execution functional entities and asoftswitch.

It is also an object of the invention to provide a method forintercommunication between individual service execution functionalentities.

It is still another object of the invention to provide a method fordynamically duplicating or ‘cloning’ individual service executionfunctional entities such that the availability of a particularapplication or application feature may increase proportionally withdemand.

It is yet another object of the invention to provide a client system forcreating, naming, cataloguing, reusing, combining and re-combiningservice execution functional entities.

It is another object of the invention to provide a server system forstoring service execution functional entities and for distributingexecutable service applications.

It is still another object of the invention to provide a client systemfor managing the server systems.

It is yet another object of the invention to provide client and serversystems for run-time management of individual service executionfunctional entities.

It is another object of the invention to provide client and serversystems for creating, naming, cataloging and distributing statetransition tables.

In accord with these objects, which will be discussed in detail below, anext generation telecommunications network architecture according to theinvention efficiently integrates and offers services in both the PSTNand an IP network. The enveloping architecture generally includessignaling gateways (SG) connected directly to the SS7 network for PSTNsignaling support, one or more service creation switches (SX) coupled toeach SG, and a plurality of media gateways (MG) (or broadband switches)coupled to each SX. Each MG includes hardware responsible for switchingand interworking (converting signals) between the IP and PSTN networks.

The SX is preferably implemented in software and includes a mediagateway controller (MGC) and a calling agent (CA). The MGC isresponsible for controlling a set of endpoints across a given set ofMGs, the set of endpoints comprising a domain. The CA contains theintelligence and policies used by the MGC to make routing decisions, aswell as provides service interworking functionality; i.e., the CA worksin conjunction with an application providing a service on a user's line.According to the invention, the SX supports both tightly coupled andloosely distributed application server (AS) functions, with the tightlycoupled AS functions (such as Class 5 services) residing in the SX, andthe loosely coupled AS functions (e.g., voice mail) carried out in aservice level executable environment (SLEE), described below. From anetwork perspective, the SX provides the basic connection controlfunction over a domain of endpoints which may be media channels in amedia gateway, subscriber line terminations in a residential gateway, ordigital circuits in a trunking gateway. The capability of the SX tosupport both tightly and loosely coupled AS functions is a criticaladvantage over other proposed next-generation solutions. According tothe presently preferred embodiment, the SLEE carries out both looselycoupled and tightly coupled services, with a portion of the SLEEembodied in the SX.

More particularly, the SLEE includes an application creation andmanagement environment which utilizes dynamically loaded sharedlibraries (DLLs) to facilitate the deployment and distribution ofenhanced services over the integrated network. The SLEE has anapplication layer, a Soft switch interworking layer, and a Media serverinterworking layer, and also includes run time commands suitable fordebugging application files. The SLEE receives service request messagesfrom an SX or user agent through an API, the SLEE Library, and isresponsible for communicating with the Soft switch interworking layerand the Media server interworking layer. In the interworking layers (thecapability layer), the SLEE loads specific application triggeringmechanisms which include a project state machine. The project statemachine is a shared library loaded by the SLEE. Each project also has adifferent state machine that governs events at a finer level. The logicthat handles each event is written in a scripting language and thencompiled into the DLLs.

The SLEE can operate in a Loosely Coupled Mode, Mode 1, or a TightlyCoupled Mode, Mode 2. From the perspective of a single softswitch, it ispossible to implement one SLEE operating in Mode 2 and one or more SLEEsoperating in Mode 1. Furthermore, from a network perspective it ispossible to implement a plurality of SLEE in either mode of operation.

When describing applications for the Decoupled TelecommunicationsSystem, there are two broad classifications, Network Applications andUser Applications.

An example of a Network application is broadband access. Broadbandaccess is a superset of functionalities that embody all of the essentialcapabilities of a Class 5 SPCS (EO/AT) in the PSTN such that the Usercannot distinguish between their Class 5 service delivered through aDecoupled Telecommunications System versus a Class 5 SPCS in the PSTN.

To achieve functional equivalence to the Class 5 SPCS in a DecoupledTelecommunications System, an equivalent state machine is createdthrough the SLEE CPL and then mobilized into the softswitch. This statemachine combines the Originating and Terminating basic call statemachines specified by the ITU for Capability Set 2. The SLEE functionwhich implements this composite state machine is the Basic Call Process(BCP). The BCP is a specialized implementation of the ApplicationServices Interworking Layer. The BCP is a byproduct of the SLEEoperating in mode 2. The BCP function facilitates tightly coupledinteraction between the SLEE and the softswitch. The BCP is the‘gearbox’, subject to the previous analogy. SLEE mode 2 is theappropriate operational mode for the broadband access networkapplication because it incorporates user services which are subject tothe ‘delay budget’.

An example of a User application is Unified Messaging (UM). Although UMis a relatively complex application, it mainly involves repeatedrequest/response pairs of user interactions where moderate delays areacceptable. SLEE mode 1 is the appropriate operational mode for the UMapplication because the delay budget is not an issue and the applicationgenerally involves lengthy interactive sessions between the SLEE andother distributed Application Server elements including media servers,messaging servers and web servers using protocols that are not typicallysupported in a softswitch.

Additional objects and advantages of the invention will become apparentto those skilled in the art upon reference to the detailed descriptiontaken in conjunction with the provided figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level schematic diagram of the next generation networkarchitecture of the invention;

FIG. 2 is a schematic of a service exchange switch (SX) for IP trafficrouting and the functionality thereof according to the invention;

FIG. 3 is a schematic of the interworking of the IP network and PSTNnetworks according to the invention;

FIG. 4 shows the multilayered SX to SG protocol, over the S1 Ethernetsignaling interface;

FIG. 5 shows the multilayered MG to SX protocol over the S2 Ethernetsignaling interface;

FIG. 6 shows a functional diagram of the interconnectivity of the SG, SXand MG, and the SLEE and Billing and Recordkeeping Server systemobjects.

FIG. 7 is a block diagram of the slee and the libraries, threads, andcall flows loaded by the SLEE which effect applications for implementingcall services;

FIG. 8 is a block diagram of a single project state machine run withinthe SLEE;

FIG. 9 is a block diagram of the SLEE DNS servers software, illustratingits scalable and distributable architecture;

FIG. 10 is a functional diagram of the basic application elementsaccommodated by the SLEE library; and

FIG. 11 shows the interaction between the basic call processing (BCP)and service level executable interface (SLEE).

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In order to facilitate understanding of the detailed description, Table1 is provided. Table 1 defines the acronyms used in the Specificationand Drawings.

TABLE 1 Acronym Definitions AAL-2 ATM Adaption Layer 2 AIN AdvancedIntelligent Network AP Application API Application Programming InterfaceAS Application Server AS1, AS2 Application Service Interfaces ASIApplication Services Interworking AT Access Tandem ATM AsynchronousTransfer Mode BCP Basic Call Processing BMS Billing Management PlatformCA Call Agent CAS Channel Associated Signaling CDR Call Detail RecordCID Call Instance Data CLI Command Line Interface CPL Call ProcessingLanguage DLL Dynamically Loaded Shared Libraries DNS Dynamic NamingServices or Domain Name Server DSLAM Digital Subscriber Line AccessMultiplexer EMS Element Management System EO End Office EO/AT EndOffice/Access Tandem GSI Generic Signaling Interface GW1 GatewayInterface HA High Availability HA1 High Availability Interface HTTPHypertext Transfer Protocol IAD Integrated Access Device IETF InternetEngineering Task Force IN Intelligent Network IP Internet Protocol IPLInitial Program Load ISDN Integrated Services Digital Network ISUP ISDNUser Part ITU International Telecommunications Union LAN Local AreaNetwork M1, M2, M3, M4 Management Interfaces MG Media Gateway (BroadbandSwitch) MGC Media Gateway Control MGCP Media Gateway Control ProtocolMIB Management Information Base MS Media server NCAS Non-ChannelAssociated Signaling NM Network Management O-BCSM Originating Basic CallState Model OSI Open Systems Interconnection OSS Operations SupportSystem PIM Protocol Independent Management PRI Primary Rate InterfacePSTN Public Switched Telephone Network S1, S2 Signaling Interfaces SCPService Control Point SDP Session Description Protocol SG SignalingGateway SIB Service Independent Building Block SIP Simple InternetProtocol SLEE Service Level Executable Environment SNMP Simple NetworkManagement Protocol SPCS Stored Program Control Switch SPM SignalingProtocol Multiplexing SS Soft Switch SS7 Signaling System 7 SX ServiceCreation Switch TALI Royalty Free Signaling Protocol Source Code fromTekelec T-BCSM Terminating Basic Call State Model TCAP TransactionCapabilities Application Part TCP Terminal Control Program TDM TimeDivision Multiplexing UDP User Datagram Protocol UNI User NetworkInterface VC Virtual Channel WAN Wide Area Network XML Extensible MarkupLanguage

Turning now to FIG. 1, a next generation telecommunications networkarchitecture according to the invention integrates PSTN and IP networks.The architecture generally includes signaling gateways (SG) 10 connecteddirectly to the SS7 network 12 for PSTN signaling support, one or moreservice creation switches (SX) 14 coupled to each SG 10, and a pluralityof media gateways (MG) 16 coupled to each SX 14.

The MG 16 is a broadband switch designed to support switching andinterworking between traditional circuit switched network (PSTN) andbroadband or “packet-based” networks such as an IP network 107 and anATM network 108 (FIG. 3). Generally speaking, the media gateway functionis to terminate multiple physical or logical ‘bearer’ channels(typically associated with User connections), and perform inter-workingbetween two or more transport mediums (e.g. TDM, ATM, IP). The mediagateway function exists in the media transport plane. As such, the MG 16includes ports (or endpoints) that when connected create a connection.Each MG has means responsible for switching and interworking (convertingsignals) between the IP and PSTN networks, and consequently hasinterfaces for both IP (packet-based) and PSTN (TDM-based) networks.

Referring to FIG. 2, the SX 14 is generally an integrated servicescreation softswitch platform which includes connection control,management capability, and the ability to host the basic call process ofthe SLEE. In this mode, it supports several high-level control domaininternal functions: basic call processing (BCP) 20, application servicesinterworking (ASI) 22, call agent (CA) 24, generic signaling interface(GSI) 26, media gateway control (MGC) 28, and network management (NM)30.

According to the invention, the SX 14 also includes carrier-readymodules including Class 5 services, and is an open service creationenvironment 34 (service level executable environment or SLEE) thatenables the rapid delivery of new carrier-class services and enhancedapplications. Briefly, the SLEE 34 includes an application programminginterface (API) called the SLEE Library which utilizes dynamicallyloaded shared libraries (DLLs) to facilitate the deployment anddistribution of enhanced services which are not subject to the Class 5delay budget over the integrated network. The basic call processing(BCP) 20 is a specialized ASI function that creates the coupling betweenthe SX 14 and the SLEE 34. The BCP 20 and SLEE 34 intercommunicate usinga special command set referred to as the SLEE library, which isdescribed in detail below. The BCP 20 is modeled conceptually on the ITUAdvanced Intelligent Network (AIN 0.2) basic call process functions.That is, the BCP 20 uses separate originating and terminating views toexpress a connection between half-calls. In the BCP 20, a two-party callis viewed as two separate half-calls each with their own connectionrelated data (context) and status (state). The BCP 20 controls all callsin the SX 14 which originate or terminate on a subscriber line. Inaddition, the BCP 20 also controls all tandem trunk to trunk (AT to AT)calls, which do not require any feature interaction with SLEE 34. Insummary, the BCP 20 emulates within the SX 14 all basic call controlfunctions of EO/AT switches currently deployed in the PSTN.

The application services interworking (ASI) function 22 manages theinteraction between SX 14 and the application service (AS) functionsresiding in the service control domain for any non-SLEE AS functionssupported by the SX 14. When the SLEE AS functions are implemented, theBCP 20 replaces the thin ASI function 22.

The call agent (CA) 24 is described by its subfunctions, which include:call admission control, call routing, call detail record (CDR)management, and database management. The call admission controldetermines which application service function (AS) is responsible forcontrolling an inbound call and selects the appropriate ASI to interfacewith a particular AS. Each AS must register with an SX 14 prior toreceiving work. Call routing uses call related information to performroute table searches and returns one or multiple trunking facilitieswhich may be used for termination. Call routing is described in moredetail below. CDR management maintains the integrity of all CDR recordsin database 36, makes CDR information accessible to other functions inthe SX 14 and periodically writes CDR data to disk. Database managementmaintains the integrity of all local SX database tables, and performsroute table synchronization between active and standby SX systems asdynamic updates are submitted through management interfaces. Generallyspeaking the call agent (CA) function is to coordinate calls and callerrelated activities and resources. Furthermore, a call agent views a callas a transaction which can include one or many participants. A callagent provides basic call related services to one or many call partiesbased on their individual service policies. The call agent controlfunction exists in the signaling and control plane.

The generic signaling interface (GSI) function 26 performs commonchannel control signal interworking between the SX and the network,specifically SS7 and ISDN PRI. The GSI 26 translates raw ISUP, TCAP,AIN, IN and ISDN message structures into generic primitives understoodby the SX 14. A generic address structure is used to carry calladdressing information between the SX and the SG, e.g. calling partynumber/sub-address, called party number/sub-address and destinationprefix. A generic circuit information structure is used to communicatecircuit connection related information between an SX 14 and SG 10, e.g.endpoint type (ISUP trunk group or ISDN access port) and circuit/channelinformation.

The media gateway controller (MGC) 28 performs interworking between anSX 14 and one or more MGs 16, and provides termination to a collectionof endpoints in one or more domains. The MGC 28 translates theconnection status (state) and call transaction specific connectioninformation (context), received through an MGC protocol (MGCP), into ageneric set of primitives understood by other SX internal functions thatmay be required to facilitate the call transaction. The MGC 28 is alsoresponsible for managing connections between the SX 14 and MGs 10,including such activities as endpoint audit and fail-over. Generallyspeaking, the media gateway controller function is to orchestrate andmanipulate the connections between two or more physical or logical‘bearer’ channels terminating on a single media gateway or terminatingbetween two or more media gateway elements. Furthermore, a media gatewaycontroller may also orchestrate and manipulate the connections betweentwo or more physical or logical ‘bearer’ channels between a mediagateway and a media server(s). The media gateway control function existsin the signaling and control plane.

Network management (NM) 30 includes a number of subfunctions related tonetwork management access control to the SX 14. The subfunctions includeconfiguration session management, alarm interface, database interface,CDR interface, and high availability (HA). The configuration sessionmanagement controls one or more sessions where a network administratoror a script emulating multiple configuration instructions is submittingconfiguration updates to the SX 14 using a command line interface (CLI).The SX is preferably run on a Sun Solaris 2.8 platform. The SolsticeEnterprise Agents (SEA) from Sun Microsystems provides a softwaredevelopment kit that enables the building of subagents to managedifferent subsystems, components and applications within a system in SunSolaris environment. The alarm interface handles alarms as SNMP traps inthe SX system. Traps are predefined within each component and, when thetrap conditions are met, components call alarm functions within asupport manager library to send out SNMP traps. The database interfaceis synchronized with a subscriber management portal centralizeddatabase, e.g., an ORACLE database. The CDR interface maintains allrelevant switch and billing information. All records are stored indatabase 36. The SX MGC/CA host generates raw (unformatted) CDR recordsfor each call from its internal database. CDR data is synchronizedbetween both an active SX system 14 and a standby SX system 14 a. Assuch, should the active SX system 14 become unavailable, the standby SXsystem 14 a is able to take over all existing operations without loss ofdata. The high availability (HA) function 38 supports redundancy in theevent of a failure. As such, the HA function coordinates all internal HArelated processes, monitors IP traffic and heartbeat messages over aserial link and two Ethernet interfaces, and determines when to performfailover and recovery functions. When a fail-over needs to occur (due toSX 14 failure), the HA operates to mediate and coordinate fail-overprocesses between the active SX 14 and standby SX 14 a systems. The HAalso manages all of the data replication required to maintain all stablecalls in the system. The data elements which require replication includeCDR records, subscriber profile data, BCP call state information, MIBdata (routing tables, IP addresses, etc.), and signaling interface calltransaction related data objects in MGC and GSI. At specified intervals,a Billing and Recordkeeping Server (BRS) 80 polls the SX 14 for any newCDR records.

In view of the above described internal functions, a typical call flowthrough the SX 14 is now described. A notify message 40 from an MG 16 tothe MGC 28 in the SX 14 signals a user off-hook event with the user ID(endpoint) and dialed digits attached. The MGC 28 makes the associationbetween the user endpoint ID and a virtual channel (VC) address usedinternally in SX 14. The MGC 28 then signals the CA 24 on the new callat 42 and the CA creates a call context and a call detail record (CDR)and appends these two objects to the calling VC object. The call contextcontains all information about the call during its active life and ismade accessible to all internal functions of the SX 14. The CA 24coordinates with the HA function 38 at 44 to provide the status of thecalling VC with the appended call context and CDR information to thestandby SX 14 a at 46. The CA 24 signals the BCP 20 on the new call at48, providing the BCP with a pointer to the calling VC object and passescontrol of further call processing of the line to the BCP. The BCP 20notes the status of the line and checks to see if any service functionis required at this stage.

Assuming the SLEE 34 needs to analyze the dialed destination, the BCP 20uses the current status of the line at 50 to determine which, if any,service function (a service independent building block or SIB as definedby the ITU) 52 in the SLEE needs to be called. If the BCP 20 determinesthat an SIB needs to be called, the SIB is called and performed on thedialed destination based on the calling party's feature profile. The SIBreturns a response to the BCP 20 which then updates the status of theline at 54. The SLEE 34 updates the subscriber profile data putting thedialed destination in the last number dialed field.

Based on the new line status, the BCP 20 signals the CA 24 at 56 toroute the call to its destination. The CA 24 performs a route lookup anddetermines a preferred PSTN trunk group (e.g., ISUP or TCAP) for thecall and whether idle capacity is available. The CA 24 coordinates withthe HA function 38 to provide the updated status of the calling VC withthe appended call context and CDR info to the standby SX 14 a at 58.

The CA 24 signals the GSI 26 at 60 to initiate a call to the user dialeddestination on the preferred trunk group. Once an idle circuit in thetrunk group is selected, its port id is passed back to the CA at 62. TheCA then creates a context and CDR for the terminating connection (calledVC) and appends these two objects to the called VC object.

During the destination call setup, the GSI 26 and MGC 28 exchangesignals at 64 that coordinate the connection activity on the selectedtrunk group bearer channel with the MG 16.

Once the called party answers, the GSI 26 signals the CA 24 at 66. Nowthe calling VC and the called VC are connected and the CA 24 updates theBCP 20 at 70. The CA coordinates at 68 with the HA function 38 toprovide the updated status of the calling VC/called VC with the appendedcall context and CDR info to the standby SX 14 a. The stable call ismaintained on an SX fail-over.

The CA 24 signals the BCP 20 at 72 with respect to the connected call,providing the BCP with a pointer to the calling/called VC objects. TheBCP 20 notes the status of the line and checks to see if any servicefunction is required at this stage. In this example, it is assumed thatthe SLEE 34 is not required. The call remains connected until eitherparty hangs up.

Assuming the called party hangs up, the GSI 26 signals the CA 24 at 74of the release from the network side, which the CA acknowledges, and theCA subsequently notifies the BCP at 76. The CA starts a process everyfew seconds which writes the CDR data into the database 36. The CAcoordinates with the HA function 38 at 78 to provide the updated statusof the calling VC/called VC with the appended call context and CDR infoto the standby SX 14 a. This releases the connection resources andgenerates a CDR in the standby SX 14 a. On a configurable time interval,the Billing and Recordkeeping Server (BRS) 80 acquires any new CDRrecords (marked ‘unread’) from the local database 36 of the SX 14 at 82(FIGS. 2 and 3).

Referring to FIG. 3, the SX functions map, through interfaces, to otherobjects, applications, and management terminals in an IP network. The SXinterfaces are grouped into the following categories: signalinginterfaces S1 and S2, gateway interface GW1, application serviceinterfaces AS1 and AS2, management interfaces M1, M2, M3, M4, and highavailability interface HA1.

According to the relationship between non-channel associated signaling(NCAS) data and bearer channels, SX NCAS signaling functions can bedivided into two classes: embedded and non-embedded. The embeddedsignaling function classification means that the signaling channel andthe associated bearer channels terminate on the same piece of hardware.For example, in traditional telecommunication equipment, an ISDND-channel is the 24th channel in a T1 (or the 30th channel in an E1)interface and all the other 23 (or 29) channels are for bearer purpose.Conversely, the non-embedded signaling classification means that thesignaling channel and the bearer channels terminate on differenthardware equipment, e.g. in the case of SS7 A-links which terminate ondedicated equipment such as a signaling gateway, while the mapped bearerchannels terminate on a trunking gateway. Channel associated signaling(CAS) in the SX 14 is a subfunction of the MGC 28.

Signaling interface S1 represents a logical connection between the SS7non-embedded signaling function 90 of the GSI 26 of the SX 14 and thesignaling gateway (SG) 10 used to deliver ISUP, TCAP, IN and AINprotocol-related information. The TCAP/AIN/IN information relates totoll-free number, local number portability, and calling party namedatabase queries.

The S1 physical interface is Ethernet over which the multilayered SX toSG protocol shown in FIG. 4 is implemented. In this protocol, the callsignaling messages received on the signaling link from a PSTN signalingend point 92 are processed by the Q.931/ISUP stack in the SG 10 andconverted into GSI primitives (e.g. connection indication, etc.). TheGSI primitives are then sent from the SG 10 to the SX 14 through theEthernet S1. Several protocol layers are implemented between the SX 14and the SG 10 to provide reliable and efficient transportation of theGSI primitives. First, a modified version of TALI is used as thetransportation layer of the protocol between SX and SG implemented. TALIpreferably runs on top of TCP/UDP and IP. TALI is a protocol originallysubmitted by Tekelec to the IETF to be reviewed for adoption as astandard, but rejected as a standard. A redundancy manager layer runsover TALI, and serves to maintain two mutual-backup connections betweenthe SX 14 and the SG 10. A signaling protocol multiplexing (SPM) layerwhich multiplexes and demultiplexes native signaling protocols, such asISDN, ISUP, ATM UNI, etc. runs over the redundancy manager layer.Preferably a backup mechanism is provided in which each SX 14 is coupledvia S1 interfaces to a pair of SGs 10. Generally speaking, the signalinggateway (SG) function is to perform inter-working between two or moresignaling mediums (e.g. SS7, TCP/IP, etc.). The call agent controlfunction exists in the signaling and control plane. The signalinggateway control function exists in the signaling and control plane.

The S2 physical interface represent a logical connection between theISDN non-embedded signaling function 94 of the GSI 26 and an ISDNendpoint 95 on the MG 16. The S2 physical interface is Ethernet overwhich the multilayered protocol shown in FIG. 5 is implemented.

With respect to provisioning the signaling information of S1 and S2, acentralized element management station (EMS) 96 of the Billing andRecordkeeping Server (BRS) 80 coordinates the provisioning of the SG 10,SX 14 and MG 16. After EMS provisioning is complete, the SG, SX, and MGcoordinate their configurations such that during operation they cancorrectly map the logical resources in common between them.

The gateway interface (GW1) manages the interconnection of the SX 14 toan MG 16, preferably using the MGCP Version 1.0 protocol. The MGC 28 ofthe SX 14 implements specific media gateway control protocol (MGCP)packages 98 for line, trunk and channel-associated signaling (CAS) withthe MG 16. For CAS, the signals are carried on the same facility as thevoice path. Since the MG 16 does not support direct termination ofanalog interfaces 102, the CAS control to the analog interface 102 isdelivered through digital supervision signaling (ABCD bits) over a DSLAM(DSL access multiplexer) 104 to an integrated access device (IAD) 106using an ATM AAL-2 loop emulation protocol at 108. The IAD 106 is acustomer located access device that can handle both voice and dataservices on the same access line and is connected to a telephone 110 atthe customer premises.

The GW1 physical interface is Ethernet over which the IP, user datagramprotocol (UDP), and MGCP protocol layers are implemented. In order tofacilitate the implementation of redundant MGCs, MGCP uses domain names,rather than IF addresses to identify the MGC and the MG. Several IPaddresses can be associated with a domain name. MGCP is atransaction-based protocol, which allows a new MGC function to take overcontrol at any given point of time. When the gateway detects a new MGCsource in a new MGCP request, the gateway then sends the associatedresponses to the new MGC, while responses to previous commands are stilltransmitted to the original source MGC.

The high availability interfaces (HA1) manage the redundancy between theactive and standby SX systems 14, 14 a. The physical interfaces utilizedby the HA1 include four Ethernet connections and one serial connection.

Management interfaces M1 and M2 are for CLI provisioning and elementmanagement (EMS), respectively. Both M1 and M2 interfaces are SNMP overUDP. Management interface M3 is used to synchronize subscriber databetween the subscriber management portal (SMP) 120 of the Billing andRecordkeeping Server (BRS) 80 and one or more SX systems 14 in thenetwork. Management interface M4 is used to pull CDR records from SXsystems 14 to the billing mediation platform (BMS) 122 of the Billingand Recordkeeping Server 80. Both interfaces M3 and M4 are TCP/IP.

The AS1 interface manages the interconnection of the ASI function 22 ofthe SX 14 to application service functions (AS) 126. The applicationserver (AS) function is to coordinate calls and caller relatedactivities and resources for specialized purposes beyond the basic callprocess and typically associated with enhanced service arrangements.Furthermore, an application server may provide feature interactionmanagement between application program functions. The application serverfunction exists in the application services plane.

The SX is adapted to support two types of AS interfaces. The firstinterface type, designated AS1, defines the logical and physicalinterface between the SX BCP 20 and the SLEE 34. The second interfacetype, designated AS2, defines the logical and physical interface betweenthe SX ASI 22 and an external AS 126 residing in the IP network. Thephysical characteristics of the AS1 interface may be implemented twoways, depending on whether or not the SLEE resides on the same server asthe SX. When the SLEE 34 and SX 14 reside on separate servers, the AS1physical interface is Ethernet over which the transport protocol used isUDP over IP. This option requires the network to support IP4multicasting between nodes, and is implemented by enabling IP multicastrouting and IP PIM on all client-server interfaces. The BCP 20 and SLEE34 communicate through a request/response API referred to as the SLEELibrary. When the SLEE and SX reside on the same server, the ASIphysical interface is UDP.

Within the SX, connection control primarily involves the signaling andgateway interface functions being coordinated by the call agent function(CA) 24, with call control residing in the basic call process function(BCP) 20. An overview of SX connection control with respect to eachinterface type is provided in Table 2.

TABLE 2 SX Internal Interfaces Int. Id Logical Interface PhysicalInterface(s) Signaling Interfaces (S-Type) S1 SX GSI SS7 to SG EthernetS2 SX GSI ISDN to MG Ethernet Gateway Interfaces (GW-Type) GW1 SXMGC/CAS to MG Ethernet; MGCP/UDP/IP High Availability Interfaces HA1 SXActive HA to SX Standby HA Ethernet, Serial Management Interfaces(M-Type) M1 SX NM to Management Terminal Ethernet, Serial RS-232 M2 SXNM to Billing and Record keeping Server EMS Ethernet M3 SX NM to Billingand Record keeping Server SMP Ethernet M4 SX NM to Billing and Recordkeeping Server BMS Ethernet Application Server Interfaces (AS-Type) AS1SX BCP to SLEE (on same server) SX BCP to SLEE (on separate servers)Ethernet; UDP/IP; IP4 Multicast pim dense AS2 SX ASI to GenericApplication Server (AS) Ethernet; TCP/IP AS3 SX SMDI to External VoiceMail System Serial RS-232

FIG. 6 also shows the interconnectivity of the SG 10, the SX 14, the MG16, the SLEE 34 with modules 124 a, 124 b, 124 c, 124 d comprised ofSIBS, and the Billing and Recordkeeping Management System 80, albeitproviding a different functional overview than FIG. 4. Both figures,used in conjunction with each other, facilitate the understanding of theinterconnectivity of objects.

Referring more particularly to the SLEE 34, the SLEE allows for theimplementation of many reusable basic application service functions(modules), referred to as service independent building blocks (SIBs) 52.These SIBs may be representative of individual call states, specializedservice functions, or the set of atomic functions specified by the ITUfor AIN 0.2. Using a call processing language (CPL), discussed below,new SIBs can be scripted which are then combined and compiled intoapplication scripts which execute in the SLEE. Because SIBS containrelatively few lines of programming code they can be easily and quicklytested. SIBs can be reused and combined with newly coded SIBs to createfuture service applications.

According to one embodiment, the SLEE implementation makes each SIB intoa separate process, with user datagram protocol (UDP) as the preferredmethod of inter-process communication. This makes the implementationcompletely distributable, driven entirely by the time-to-live attributeof the UDP message, which determines the scope of distribution (e.g.,LAN segment, WAN, or world-wide network). As such, new features can bebuilt and tested, and then sent to a customer system by reference in theSLEE Dynamic Naming Services (DNS) server which, as discussed below,permits the distribution of functional elements over the network. Withinthe SLEE, multiple copies of any SIB can be run as the call loaddirected to a particular service function or feature peaks. Conversely,distribution of services can also be implemented by having a single SLEEconnect to multiple SXs across the IP network. Rather than forcingapplications or the SX to learn the details of using the SLEE DNSserver, the SLEE Library, referenced above and described in detailbelow, is provided to make the interface clean and easy.

According to the presently preferred embodiment, the SLEE isinstantiated by a C-language program module named slee. The sleeexecutable is a generic implementation of very basic SLEE functions.Consequently, it can run in a variety of environments, wherever servicelevel execution is desired: at the application level, as part of theservice creation switch (SX), or embedded within a Media Server (MS) ora similar device. A Media Server generally provides interworking betweenthe SLEE and a media server which preferably supports HTTP. A mediaserver functions to terminate one or many physical or logical ‘bearer’channels (typically associated with User connections) into an ephemeralresource (dynamically loaded digital signal processor-attachedresource). Furthermore, a media server may mix one or many physical orlogical ‘bearer’ channels into a multi-party conference. A media serveris differentiated from a media gateway through its ability to provideenhanced services to a bearer channel (e.g. speech recognition,interactive voice response scripts, text-to-speech, etc.). The mediaserver function exists in the media transport plane. In effect, themedia server is the capability layer of the SLEE. The combination of theslee and the libraries, threads, and projects loaded by it make up theactual application. A call flow is implemented within a project.

Referring to FIG. 7, the SLEE 34 is shown with a number of projects 130loaded in the lower right hand corner, a pool of threads 132 in thelower left hand corner, and three fixed threads 134, 136, 138 along theleft side. Fixed thread 134 provides for communication between the SLEEand another node on the network. Fixed thread 136 provides for operatorcommands to control and monitor the SLEE while it is running. Fixedthread 138 provides for communication with the SX. For each project 130that the SLEE 34 runs, a thread is retrieved from the thread pool 132,and the thread then runs the project-specific code. The SLEE moduleprovides for balance between the threads that instantiate the projects.

The fixed threads govern a variety of interfaces, one interface perthread and one thread per interface. The fixed threads are written asC-language source modules and linked into the slee at compile time. Aconfiguration file slee.cfg governs which threads are loaded, and theorder in which they are loaded. Fixed threads include the following:

opcmds thread (sleecmd.c)

This thread is the command thread, and provides a keyboard interface tothe SLEE to allow reconfiguration, shutdown, and similar commands.

sleenode thread (sleenode.c)

This thread allows communication between the SLEE in a subject node andthe SLEE in other nodes. This thread also accepts requests from othernon-SLEE services to the SLEE (e.g., a request from the notificationprocess that the SLEE make calls to pager bureaus, and to send CDR's fornotification events handled by the notification process).

database interface thread (sleedam.c)

This thread waits for database events to occur and forwards these eventsthrough the main SLEE thread to the appropriate call flow.

timer thread (sleepuls.c)

This thread tracks the time remaining for an array of script-managedfunctions. When each timer reaches zero, the call context in informed,and any wait condition pausing the script is interrupted.

Media server thread (sleemm.c)

This thread waits for events from the Media server. When a new eventarrives, it is part of SLEE's queue. The SLEE's main thread forwards theevent to the appropriate call flow in order that the script handles theinformation returned by the Media server.

Soft switch API thread (sleerm.c)

This thread manages the API with the Soft switch. When a new eventarrives, it is placed on the queue for the slee main thread, whichforwards the event to the appropriate call flow.

The various SLEE fixed threads have input and output mechanisms thatdiffer based on the purpose of the thread.

SLEE main thread (slee.c)

This thread services a linked list of queue of events. All the otherthreads add events to this queue through a function within the main sleethread called slee_addEvent. This thread removes events from its queueand adds them to the linked list queue for the appropriate call flow.

sleecmd thread

This queue removes its input from a UNIX message queue. Its output istypically to a file called /usr2/USM2/LOGS/slee.out.

sleedam thread

This thread gets all new input from the database interface (DBIF)through a call to the function Get_Database_Response. The output is tothe slee event queue.

sleepuls thread

This thread has no input. Rather, scripts can initialize one of fivefunction timers through a statement with the syntax:

setContext(funcTimer[x], VALUE)

The funcTimer[0] tracks the number of seconds left before ANM (answer)is returned to the network. The call to set the high limit is

setContext(funcTimer[0], thisContext→timer[21])

When this timer expires, the function signalCall (in sleecall.c) causesnotification to the thread handling the call in progress that the timerhas expired. Threads can test the value of the timer (including when itreaches zero) by checking the value of thisContext→funcTimer[x]. Thesignal to the thread that the timer has expired will affect any currentwaits or timed waits.

sleemm thread

The input for this thread is through the function call in mmlib.c namedmm_EventGet( ) The mmlib code manages TCP/IP socket connections to thevarious Media server servers. Output is to the slee main event queue.

sleerm thread

Input to this thread is through the TCP/IP socket connection thatunderlies the open API. Output is to the slee main event queue.

Referring to FIG. 8, the project state machine contains the logic thatimplements a project 130. Each project 130 can have a different statemachine that governs the meaning of events at a finer level than thecall states. Each project state machine 140 is a shared library loadedby the slee module, and pulls messages off of a linked list created bythe slee module and processes each as a separate event. The statemachine tracks the context of each event and the result of each eventhandler (script).

The logic that handles each event is written in scripts in a callprocessing language (CPL), and then compiled into dynamically loadedshared libraries (DLLs). Each state machine 140 governs a pool 142 ofthreads that handle active calls. The threads make calls to the sharedlibraries, to the state machine, and to the slee module.

The slee module is invoked as a separate process at the applicationlayer with a parameter that indicates the level at which it implementsthe SLEE, as follows:

SLEE/BIN/slee AP to run at the application level

The slee is run within its own thread in the Soft switch (if it runsthere) and in the Media server. The entry point is a routine named slee(), which takes two parameters: the level at which it is running, and thepath to the configuration information:

int slee (“SS”, path); to run within the Soft switch

int slee (“MS”, path); to run within the Media server

The return code indicates whether the SLEE was able to initialize (0) ornot (some negative value). All of the calls to MS devices that usedevice drivers that are not thread safe, are through calls back throughthe slee thread, which may in turn call routines in the module thatlaunches it. It is necessary for the slee to know at which layer it isoperating because, depending on the layer, different scripts are loaded.

Also in the SLEE directories are the dynamically loaded shared libraries(DLLs) that provide the API between the layers. In the case of the APdirectory, there is a DLL that provides inter-node communicationservices; e.g., Access Node to Service Node, Guaranteed Delivery, etc.The shared libraries also provide basic services such as trace filelogging, alarm and trap notifications, etc. The shared libraries arepreferably compiled for the specific operating system in which they run.

The slee module loads the unique processing logic (project statemachines) for the various projects, and receives the run-time commandsdiscussed below.

The application layer slee has several functions. First, the applicationlayer slee module receives all messages from the SS through the selectedAPI, e.g., an interface such as PARLAY™ (from the Parlay Group) andS-100. The received message is then added to the appropriate linked listfor the project that the message pertains to, and the project isnotified to handle the message. Second, the application layer sleemodule is also responsible for communicating with other layers. Third,the application layer slee module controls connections to other nodeslike Access Node to Service Node, the Guaranteed Message Deliverysystem, and the database. Fourth, the application layer slee moduleloads the node configuration details and makes them available to thevarious project state machines.

According to the preferred embodiment, the slee module is preferably notloaded in the Soft switch (SS) layer. However, given an appropriatefunction, the slee module may be loaded in the SS layer.

In the Media server, the slee is responsible for loading specificproject logic where necessary.

By way of example, the following high level pseudo-code forimplementation of the slee module is provided:

-   -   Confirm that the Layer parameter is one of AP or SS or MS.    -   Load the configuration file slee.cfg.    -   For each shared library listed in the slee.cfg file,        -   Load the shared library from /SLEE/BIN/Layer.        -   If the file is missing, generate an alarm and shut down            gracefully.        -   If application layer, load the node parameters such as            native language, node address, and address of the nearest            Service Node.    -   For each project subdirectory in /SLEE/BIN/Projects/Active:        -   Launch the state machine for the project as a separate            thread, passing the Layer parameter and the node            configuration information.    -   Create a thread scheduling pattern that will round-robin through        the projects when scheduling control is necessary.    -   Do until stopped:        -   Receive messages from other layers.        -   Add the message to the proper linked list for the project.            The project is determined from the combination of span,            channel, and node received on each message from the Soft            switch.        -   Signal the project thread that a message was added to its            list.

Each slee module has a control thread that reads a message queue for runtime commands that can be entered at a keyboard. A separate module namedtellslee knows how to communicate with the command thread through themessage queue, and an operator can send messages directly to the sleemodule to affect how it runs. Commands all have a prefix that can betested (e.g., “!!”) and then one of a series of standard commands:

-   -   SHUTDOWN: gracefully shut down all the projects and the slee        module itself.    -   KILL #: gracefully shut down a single project (whose ID is given        in #) if possible, if not possible to cause a graceful shutdown,        force an ungraceful shut down.    -   KILL ALL: gracefully shut down all projects.    -   TRACELVL #: set the trace level to the number indicated by the        digit ‘#’.    -   LOAD: load or reload a project state machine or a shared        library.    -   SHOWCFG: display a list of the currently running projects, and        other tables and global variables to a file in /tmp for        inspection.    -   SHOWLIST #: show the messages stored on linked list ‘#’.    -   SHOWLIST ALL: show the messages stored on all of the linked        lists.    -   THREADS: show a list of all of the threads.    -   CANCEL #: cancel thread number # in the list.    -   CANCEL ALL: cancel all threads in the list

As discussed above, the slee module launches the project state machineappropriate to the state machine's level of execution, AP (Application),SS (Soft switch), or MS (Media server). The files that control theproject state machines and the compiled scripts are contained indirectories designated for the level of execution:

/usr/SLEE/BIN/Projects/Active/ProjectName/AP/usr/SLEE/BIN/Projects/Active/ProjectName/SS/usr/SLEE/BIN/Projects/Active/ProjectName/MSIn addition to the Active directory, there is a directory namedInactive:

/usr/SLEE/BIN/Projects/Inactive/ProjectName/AP/usr/SLEE/BIN/Projects/Inactive/ProjectName/SS/usr/SLEE/BIN/Projects/Inactive/ProjectName/MSThe Inactive directory is used to store test configurations or newprojects while they are being uploaded to the node. Projects that arebeing decommissioned can also be moved into this directory. Thedirectory can also hold reserve copies of previous versions of a projectin case a roll back to a previous version is necessary.

Each of the Active and Inactive directories contain a file namedinventory that names all of the scripts that should be loaded by theproject state machine.

A separate thread handles each event for a call. The threads make callsto the shared libraries, to the state machine, and to the slee module.When the thread completes its handling of the event (that is, when thescript is completed), the thread is returned to the thread pool.

The transitions in the call states are the responsibility of the projectstate machine in the application layer and its interface to persistentcall objects. Therefore, SLEE elements in the Soft switch and the Mediaserver must trigger events in the application layer to effect thechanges in the call's call state.

An unexpected release of the call by the caller will generate an eventthat will cause the Soft switch to broadcast an asynchronous releaseevent to the application and the Media server.

By way of example, the following high level pseudo-code forimplementation of the project state machine is provided:

-   -   Confirm that the Layer parameter is one of AP or SS or MS.    -   Read the project global configuration variables from the        database.    -   Load the file        /usr/SLEE/BIN/Projects/Active/ProjectName/Layer/inventory.    -   For each file in the inventory,        -   Load the script.    -   Create a thread scheduling pattern that will round-robin through        the projects when scheduling control is necessary    -   Receive messages from the slee.    -   Get a thread from the pool (or create a new thread) to handle        the message.

Each project state machine also has a control thread that reads amessage queue for run time commands that can be entered at a keyboard. Aseparate module named tellproj knows how to communicate the commandthread through the message queue, and an operator can send the messagesor commands described above (SHUTDOWN, KILL #, TRACELVL, etc.) directlyto the slee module to affect how it runs.

The inner workings of the SLEE can be monitored real time with thefollowing command: display.sh. The results are written to slee.out.

The command to show the names of scripts as they execute is:

tail -f slee.log|grep AP_(—)

The command to display the names of prompts as they play is:

tail -f slee.log|grep V9

The command to be able to see each Soft switch event as it arrives is:

tail -f slee.log|egrep “sw_|Rm”

The command to view the results of Media server functions as they arereported to the SLEE is:

tail -f slee.log|grep “API=”

The command to see whether the SLEE is receiving calls is:

tail -f slee.log

The command to change the ISP service addresses while the SLEE isrunning is:

tellslee ISP 0=phone_number Callflow

The current settings of an ISP modem can be viewed by either:

tellslee showisp Callflow

tail slee.out

or:

cat isp.cfg

Call Processing Language

As mentioned, the call processing language (CPL) is used to createscripts for the SLEE. A script, as briefly described above, is an eventhandler or a system independent building block (SIB), either high-levelor low-level. Since events of telephony significance can take place onall layers of the OSI stack, the CPL does not limit itself to theApplication Layer. Instead, CPL scripts can be executed in a variety ofenvironments. The first layering scheme separates the functionality ofthe application logic from the Soft switch and the Media server.

Each call is represented in the application layer by a persistent callobject “owned” by the application layer that maintains a number of itemsrelevant to a call. “Ownership” means responsibility to maintain the“call state”. Since the application layer “owns” the call object,changes to the call object are made only through the application layerscripts. Scripts at other layers have to generate (“trigger”)application events to change information in the call object. The callobject contains the subscriber profile data, the cumulating CDR data,and the application state of the call besides the call state. Theapplication state is a variable that tracks the most recently handledevent and the event next expected.

“Call state” means the state of the call in the sense described in thedocumentation for PARLAY™ or some similar standard application server.Whenever an event in any layer would change the call state, anapplication layer event must be triggered so that the application layerwill change the call state within the persistent call object.

As a call progresses, parts of the persistent call object are sentbetween the application layer and the layers lower in the OSI stack, andpossibly back up to the application layer. The result is that each callis controlled by the application layer.

According to a preferred embodiment, scripts written in CPL are compiledinto C-language statements, which are then compiled into sharedlibraries by a standard C compiler for the target computer. The compileris made up of a specification preferably developed with the C code yacccommand, a parser preferably developed with the C code lex command, andpreferably a number of C code and header files. Once a script iswritten, the command to generate C code from the script is cplSCRIPTNAME.cp. The output is a file named SCRIPTNAME.c. The C code isthen compiled into a shared library according to the specifications ofthe target platform. The importance of implementing the scripts asshared libraries is that scripts can be dynamically loaded; even at runtime, a command can be issued to load a new copy of a script. Any newcalls made will use the newly loaded version. The command interface forloading the new version of a script as a dynamically linked library isdescribed above. On the Linux operating system, it may be necessary tolink the scripts together into a single large linked library thatrepresents a whole call flow. The call flow can be changed during runtime as described above, but it is not possible to change individualscripts at run time.

The scripts for the CPL are written as plain ASCII files with new-linedelimiters. Scripts are composed of sections. Some sections arerequired, and other sections are optional and appear only when requiredby the script.

Scripts can request the execution of other scripts, either at the samelayer of execution, or at other layers. “Run” or “jump” are the twopossible commands when a script executes another script within the samelayer; that is, if an application script runs an application script).The command “run” is used if the original script expects to continuerunning after the other script has begun executing (synchronously, likea subroutine call). The syntax is run SCRIPT(parameters); for example,

run AP_MainMenu(thisContext).

The command “jump” is used if the original script is now finished andthe other script will complete what the original script might have done(asynchronously, like fork and exec). The syntax is jumpSCRIPT(parameters); for example,

jump AP_VoiceRoute(thisContext).

For instance, if there is a script that has been written to prompt auser with a question that will elicit a “yes” or “no” response(MS_Yesno), when another MS script wants to ask the user a yes or noquestion, the original script can “run” the MS_Yesno script. If there isa script that plays a “Goodbye” message and hangs up on the caller(AP_Bye), any AP script that wants to hang up on the user in thatfashion would “jump” to the AP_Bye script.

A script can run another script in the background. The second scriptruns (in part) in parallel with the first script. The second script iscalled the “child” script, and the original script is called the“parent” script. The child script inherits certain features from theparent, including the call reference number that will tie CDR's producedby the child with the CDR's created by the parent. The syntax is: bgrunSCRIPT(parameters); for example,

bgrun AP_PrintFax(faxFileName,destination, “FAX”, removeflg)

If a script running in one layer wants another layer to execute ascript, it will “trigger” the running of the script with the command<LAYER>_trigger, where <LAYER> will be:

MS for Media server,

SS for Soft switch, and

AP for application.

Scripts being run by the Soft switch or the Media server are preferablynot allowed to span changes in the call state. Such changes arepreferably required to be requested at the application level, where thecall states are tracked.

A script itself is delimited by the “start script” and “end script” keywords. As such, the first non-comment or blank line must contain onlythe key words “start script” and a new line character. The lastnon-blank and non-comment line must contain only the key words “endscript” and a new line character. Incorrectly formatted key words areignored. Hence, required key words incorrectly formatted will be flaggedas absent, and the script will not compile.

Scripts return a value of “SUCCESS” or “FAILURE.” The return valuesignals to the requesting layer whether the values in the interfacebuffers are of any value. A return of FAILURE would indicate that thecontents of the interface buffers are undefined. A return of OK wouldindicate that the contents are set as expected. Returns are coded withinthe then or else section with the keyword RETURN plus SUCCESS orFAILURE. Actually, the “SUCCESS” keyword is translated into (void *)thisCall, where “thisCall” is the address of the call object, and the“FAILURE” keyword is translated to (void *)NULL.

Comment lines begin with a hash (‘#’) in the first position. Commentsare allowed anywhere within a script, including before the “startscript” and after the “end script” keywords. Blank lines; that is, linesconsisting only of white space and a new line, are allowed at any point.

The header and code sections, described individually hereafter, arerequired to be in all scripts. The ibuffer (input buffers), obuffer(output buffers), prompts, and counters sections, also describedhereafter, are optional, and their absence is not considered to be anerror unless reference is made to them.

The header section begins with a line consisting of only the keywords“start header” and a new line and ends with a line consisting of onlythe keywords “end header” and a new line. Each field within the headerconsists of a keyword plus white space (any number of tabs or spaces)plus a value. The header must include required fields, and may includeoptional fields.

The following fields must appear in the header, and in the followingsequence.

ScriptName VALUE VALUE must start with: MS for Media server, SS for Softswitch, or AP for Application.The two-letter prefix is followed by an underline, and then anyalpha-numeric characters. Preferably, scripts are named so that theirpurpose can be determined from the name.

Example: MS_NewCall. ProjectNo VALUE VALUE must be numeric. Example:62357. ProjectName VALUE VALUE is the overall (meta-) project. Forexample: ProjectA. CreationDateVALUE VALUE is the date that the scriptwas created, in ISO-8601 format. Ex: March 16, 2000 appears as“2000-03-16.” ExecutedBy VALUE VALUE shows which layer executes thescript. Valid choices are: MS for Media server, SS for Soft switch, andAP for application. Release VALUE VALUE is a description of the releaseof the CPL that the script is intended for. Customer VALUE VALUEdescribes the customer for whom the application is designed. The VALUEcan consist of more than one word. Application VALUE VALUE is the namegiven by the customer to the application that the script pertains to.For example, R******. The VALUE can consist of more than one word.

The following fields are optional and only appear if necessary:

UpdatedBy VALUE VALUE has the name of the person who last edited thescript. For example, DFreedman or David Freedman. UpdatedOn VALUE VALUEholds the date and time that the script was updated, in ISO-8601 format.For example, 8:53 PM of March 16, 2000 appears as in this field as2000-03-16 20:53.

An “input buffer” (ibuffer) is a buffer with data (input parameters)that is provided by the level that calls the script. An ibuffer, whenpresent, begins with a line that has the words “start ibuffer” and a newline, and ends with a line that has the words “end ibuffer” and a newline. The ibuffer section can contain up to five buffers. Each ibufferdescription consists of the name of the buffer and the size of thebuffer in bytes.

When the ibuffer section compiles, the name of each buffer becomes:

char *buffername;

The pointer points to a field, thisContext→parms[x].value, where x is anumber between 0 and 4. An example of an ibuffer is

start ibuffer   profile 8   project 32 end ibuffer

An obuffer section declares the buffers necessary during the executionof the script. The compiler executes a malloc( ) call for each obuffer,using the size of the buffer as a parameter. Buffer names have scriptscope. An obuffer section, if present, begins with a line that has thewords “start obuffer” and a new line, and ends with a line that has thewords “end obuffer” and a new line. The obuffer section can contain anynumber of buffers. The script refers to the buffers by name. Eachobuffer description consists of the following and the size of the bufferto reserve. An example of an obuffer is:

start obuffer   account 16   callerName 128   callerMsg 128 end obufferThe prompts section is optional and is present only if the script willplay prompts. The prompts section begins with a line with the keywords“start prompts” and a new line, and the section ends with a line thathas the keywords “end prompts” and a new line.

The VOX file is established by the keyword language discussed below. Theindividual prompts are listed in a two-part line, with the actualVOX-prompt name (up to 12-bytes), followed by an optional description.An example of a prompts section is:

start prompts   V900111 Welcome to Platform   V920611 Please Enter Lastdigits of your account   V920411 Sorry Not Valid account number  V900411 Sorry this account is temporarily closed end prompts

The optional counters section is a list of script counters that cangovern script flow. The section begins with a line that has the keywords“start counters” and a new line, and it ends with a line that has thekeywords “end counters” and a new line. The counters themselves aredeclared a name; for example, “retries.” Within the script code, thecounters are referred to by their names. For example, given thedeclaration “retries”, to increment the counter “retries” the scriptcode would be “retries +1.” Counter names have script scope.

The code section is required and contains what the script actually does.The code section begins with a line with the key words “start code” anda new line, and ends with a line that contains the key words “end code”and a new line. Each line of code can have the following elements, andonly in the order specified.

The code section can have an optional code label field. The labels canbe numbers or names. Name labels begin at the first position on the linewith a colon, followed by label's name, as in :CLI_Blacklisted.

The code section can also have a keyword language. If a prompt is to beplayed, the keyword language followed by a valid choice sets thelanguage in which prompts (VOX files) are to be played. The validchoices for the language keyword are the “native” and “subscriber”. Thekeyword “native” identifies the native language of the node or DNS onwhich the script is running. The keyword “subscriber” identifies thelanguage selected by the subscriber in which to hear prompts.

If a prompt is to be played, the keyword prompt is followed by the nameof the prompt selected from the list of prompts in the prompts sectionof the script:

Vnnnnnn means a prompt from a VOX file (the VOX file is specified by thelanguage statement) A digit string means to recite the number withallowances for language variants A var nameThe syntax is then:

prompt({promptName1;promptName2;variableName,smartMode;

“digitString”, smartMode; . . . }, timer, digitsToGet,trapMask),

where the content between {and} is what is played to the caller, timeris the index of the timer in the timer array that is the max time forinput collection referred to as Tnumber (for example, “T22”),digitsToGet is the maximum number of digits to get from the caller, andtrapMask is a double-quote delimited string of zeroes and ones that turnup trap detection on (‘1’) or off (‘0’). “Traps” are terminationconditions that can end input collection. Traps include:

MAXWAITTIME Maximum initial silence

IDDTIME Inter digit silence timer

STAR The star key (*) was pressed

POUND The pound key (#) was pressed

MAXSIL Maximum silence was detected

MAXTIME Maximum functional time

TONE An expected tone was detected

The material between {and} need not appear in any specific sequence.Each item, except the last, ends with a semicolon.

-   -   promptName1: Name of a prompt    -   promptName2: A script can store a prompt name in an obuffer        variable and request playing the prompt        Two reasons for grouping prompt names is that the termination        condition will stop all of the output in the statement. That is,        if the POUND trap is on and the caller presses ‘#’ during the        playing of promptName1, all output will stop and the SLEE will        resume on the next line of script.

variableName, smartMode:

-   -   The request is to play the digits contained in the script        obuffer named variableName. The smartMode flag tells the Media        server how to group the digits. The current values are:    -   MS_SMARTNUM_NAMED_PROMPT=0        -   treat the string as a prompt ID.    -   MS_SMARTNUM_SPEAK_ONE_DIGIT=1        -   speak each digit, one at a time.    -   MS_SMARTNUM_SPEAK_TRIPLETS=2        -   recite the digits in groups of three.    -   MS_SMARTNUM_SPEAK_HUNDREDS=3        -   plays the digits four at a time.    -   MS_SMARTNUM_SPEAK_AND_TRIPLETS=4        -   plays digits 3 at a time, uses “and” and “hundreds”.    -   MS_SMARTNUM_SPEAK_AND_HUNDREDS=5        -   plays the digits four at a time, uses “and”, and “hundreds”.

“digitString”, smartMode

-   -   Plays a specific digit string enclosed in double-quotes using        smartMode as above.

If a built-in routine is to be called, the keyword execute appearsfollowed by the name of a built-in routine to execute and itsparameters. The parameters to the routines follow the name of theroutine in parentheses; for example, “DTMF (parm1, parm2, . . . , parmN,trapMask)”.

The trapMask field is a bit-map of events or “traps” known to thesubroutine. Each trap is a termination condition. If the routineunderstands eight traps, the trapMask can be thought of as an 8-toggleswitch. If all 8 bits are off, the toggle looks like this: 00000000. Ifthe script wants to know that the second trap happens (or “fires”), thetrapMask would look like this: 01000000. In other words, the bits arenumbered from the left, beginning with 1. To instruct the script tobehave a certain way if the trap fires, the script author writes asequence line with the notation:

if (trap2) then . . . else . . .

The else is optional. The notations become clearer in view of thefollowing discussions of the keywords if, then, and else. The built-inroutines will return if any of the traps is set in the trapMask and thesituation trapped becomes true. If the script has execute DTMF( ) withthe trapMask enabling any of those traps, and during the course of theexecution of the DTMF function one of the enabled situations happens,the built-in routine will return execution to the script with a returncode that indicates what trap occurred. A script statement containingthe keyword if followed by the condition in parentheses that matches thetrap will change the flow of execution appropriately. For example, ifDTMF was called and the trapMask was 00100000, it would mean that thescript author wanted to trap only the situation of maximum number ofdigits pressed. Preferably, the following line is provided in thescript:

if (trap3) then LABEL

or, if there is need for an else clause (typically the last trap in aseries):

if (trap3) then LABELm else LABELn

If present, the trapMask is the last parameter.

An operation consists of a counter, an arithmetic operator (e.g., plusor minus) and an optional operand. A counter can be referred to by itsname in the counter section in the script header. Counters areinitialized to zero by default. The valid operations on a counter areshown below. Note that there is a space between the counter and theoperator, and no space between the operator and the operand.

counter =VALUE

counter +VALUE

counter −VALUE

counter *VALUE

counter /VALUE

The if keyword followed by a condition in parentheses is optional. Forexample:

if (account ==“**”) then TwoStars

states that if the buffer named “account” has the value “**” (beginswith two stars), then continue at the label TwoStars. The expressionbetween the parentheses “(account ==“**”)” is called a condition. Ifthere is any other value in the “account” buffer, continue at the nextline of the script. Every if statement must be followed by a conditionand a then statement. The else is optional, and will only be present ifit makes sense. Note that a trap that has fired is treated like acondition, and one can say “if (trap2) then . . . ”.

The valid operators are:

< “less than” for arithmetic comparisons

<= “less than or equal to” for arithmetic comparisons

== “equal to,” both for arithmetic and string comparisons

> “greater than” for arithmetic comparisons

>= “greater than or equal to” for arithmetic comparisons

If there is no if or else clause in a line of code, the default is tocontinue on the following line of the script.

In order to facilitate understanding of the CPL, the following samplescript is provided:

# This script is a subroutine that plays the owner's Status Messages # #Reference: ABCSample Service Logic # Unified Messaging High Level VoiceMenu Structure#--------------------------------------------------------------------start script start header ScriptName: AP_MailboxLimit ProjectNo:   2001ProjectName: XYZProject CreationDate: 2001-02-09 ExecutedBy: AP Release:  A Customer:   ABC Application: Sample UpdatedBy: John Q. SmithUpdatedOn: 2000-03-02 12:00 end header # no ibuffers #start obuffer #endobuffer #start counters #end counters start prompts   V903511 Warning,your mailbox is full. end prompts start code#------------------------------------------------------------------- #Mailbox usage >= 100%. This message is NOT interruptible.#------------------------------------------------------------------- #Warning, your mailbox is full.   cpl({V903511},0,0,“”)   waitforPROMPT_COMPLETE   return SUCCESS end code end scriptSLEE Domain Name Service (sleedns)

In accord with a preferred aspect of the invention, a Dynamic NamingService (DNS) for the SLEE is provided. The sleedns permits service tobe distributed over multiple segments in a network.

The sleedns module starts early in the IPL sequence of an applicationservice. It accepts requests over UDP on a defined port. Whenapplications or application elements open their own ports for listening,the library function that performs the socket and bind commands sends aUDP registration request to the local sleedns process. The messagecontains the name of the element, the hostname of its host, the IPaddress of the host, and the port that the element listens on.Application elements that want to send to another application elementissue commands in the format:

sendTo(“elementName,”messagePointer, sizeof message);

The sendTo function has the responsibility to query the sleedns to lookup the host, IP address, and port for the named element, and to send theUDP message to that port on that host. The sendTo function keeps a tableof recently used addresses so that it is not necessary to do a sleednslook up for each message. The table contains all the occurrences of thenamed element, and the local server gives precedence to the localserver, but is capable of sending messages in a round-robin fashion toother hosts.

If a processing element is over-burdened, it preferably deregisters withits local sleedns, and the local copy bears the responsibility to updateall the network copies. Thus, the application element is no longer insight. It is the responsibility of the local copy of sleedns to remainsynchronized with the other network copies. This can be accomplished bysending multicast messages to all listeners in the network on thesleedns port.

A number of predefined messages are known to the server. All messages toand from the sleedns are preferably in Session Description Protocol(SDP) or XML format, and some (indicated below) have responsesassociated with them. If a response is not received before theexpiration of the timer (configured in a configuration file), therequest is repeated.

An application element registers that is ready to receive messages. Theregistration is done at initialization. The local sleedns is responsibleto multicast the new location to all the other sleedns servers in thenetwork. Each registration is stored with the time of its receipt. Ifthe application element is already registered, the entry in the DNS isupdated with the new time, and success is returned.

The Session Description Protocol (SDP) request to register anapplication element consists of the fields shown in Table 3. A semicolonseparates fields from each other, and the order of the fields is notimportant. An example registration request would look like:

r=ST4;p=20806

TABLE 3 SDP Registration Request Fields Field Required Comments From theExample r = ElementName Required ElementName can be a “ST4” is short formaximum of 31 bytes. “State4.” There is enough room to be clear aboutthe name, as in “ST_Alerting.” p = port Required In network byte order“20806” is how the network byte order for 18001 is reported by Linux onIntel x86's. h = Hostname Optional Maximum size of NI_MAXHOST-1 (1023).i = HostTCPaddress Optional In IPv4 dot notation.

The reply is the request, with a new result field, and the optionalHostname and HostTCPaddress fields supplied. The reply to the examplerequest is in the following format:

k=ACK;r=ST4;s=r;h=cpci_(—)1.techcontrol.com;i=10.4.1.32;p=20806

If the request is rejected (for any reason), the response is in thefollowing format:

k=NAK|reason;r=ST4;s=r;h=cpci_(—)1.techcontrol.com;i=10.4.1.32;p=20806,

with the fields identified in Table 4.

TABLE 4 SDP Registration Replies Fields Field Required Comments From theExample k = ACK k = NAK|reason ACK or NAK is required, Supplied by theDNS Note that if a NAK has a the reason is optional server. reason,there is a vertical bar between the word “NAK” and the reason, whichcould be several words, such as “no room in table.” r = ElementName Fromthe request. s = r p = port From the request. h = Hostname From therequest, or supplied by the DNS server. i = HostTCPaddress From therequest, or supplied by the DNS server.

Application elements can query the sleedns for the address of anotherelement. This is done by the library routine sendTo without theknowledge of the application. The SDP version of the query request lookslike:

q=ST3;p=20806

The fields in the request are described in Table 5.

TABLE 5 SDP Query Fields Field Required Comments From the Example q =ElementName Required ElementName can be a maximum of 31 bytes. This iswhat to look for. p = port Required In network byte order “20806” is howthe network byte order for 18001 is reported by Linux on Intel x86's. h= Hostname Optional Maximum size of NI_MAXHOST-1 (1023). i =HostTCPaddress Optional In IPv4 dot notation.

The reply to a query preferably has as many of the fields supplied aspossible; for example,

k=ACK;q=ST3;s=r;h=cpci_(—)1.techcontrol.com;i=10.4.1.32;p=20806

If there are no registered instances of the ElementName, the reply is asfollows:

k=NAK|Entry not found;q=TCS;s=q;h=cpci_(—)1.techcontrol.com;i=10.4.1.32;p=20806

The fields in the reply are described in Table 6.

TABLE 6 SDP Reply Fields Field Required Comments From the Example k =ACK k = NAK|reason ACK or NAK is required, Supplied by the DNS Note thatif a NAK has a the reason is optional server. reason, there is avertical bar between the word “NAK” and the reason, which could beseveral words, such as “no room in table.” q = ElementName From therequest. s = r Status of the On a NAK, the status will ElementName. Canbe be ‘q’. ‘r,’ ‘R,’ (for “registered”). p = port From the request. h =Hostname From the request, or supplied by the DNS server. i =HostTCPaddress From the request, or supplied by the DNS server.

An application element can hide itself from other elements byderegistering with the local sleedns. The local server is responsible toderegister the element by multicasting to all the other servers on thenetwork. Each deregistration is stored with the time of its receipt. Ifan attempt is made to deregister,an element that is alreadyderegistered, the DNS entry is updated, and the return will indicatesuccess. Deregistering a non-existent element is also treated as asuccess.

The request to deregister an element is provided in the followingformat:

d=ST1;p=20806,

with the fields described in Table 7.

TABLE 7 SDP Deregistration Requests Fields From the Field RequiredComments Example d = ElementName Required ElementName can be a maximumof 31 bytes. p = port Required In network byte order h = HostnameOptional Maximum size of NI_MAXHOST-1 (1023). i = HostTCPaddressOptional In IPv4 dot notation.

The SDP version of the reply to a deregistration request is in thefollowing format:

k=ACK;r=ST1;s=d;h=cpci_(—)1.techcontrol.com;i=10.4.1.32;p=20806

If the deregistration fails for any reason, the reply beginsk=NAK|reason, with the fields described in Table 8.

TABLE 8 SDP Deregistration Request Reply Fields From the Field RequiredComments Example k = ACK or k = NAK|reason ACK or NAK is required, thereason is optional r = ElementName From the request. s = d Supplied bythe DNS server. p = port From the request. h = Hostname From therequest, or supplied by the DNS server. i = HostTCPaddress From therequest, or supplied by the DNS server.

Each sleedns server communicates with all the others on the network. Thesynchronization messages are multicast to the sleedns port on all hosts.The synchronization messages look like the original requests, with allof the optional fields filled out by the sending server. The statusfield is changed to upper case so that registrations are forwarded withstatus set to ‘R’ and deregistration messages have a status of ‘D.’

Each host periodically multicasts a heartbeat message to the otherhosts. The time between heartbeats is set in the configuration file. Theheartbeat message contains a count of registered elements and the timeof the last update. An example of a heartbeat message is the following:

b=967230863;e=14;i=10.4.1.32;p=20550,

with the fields described in Table 9.

TABLE 9 Heartbeat Message Fields Field Required Comments From theExample b = UpdateTime Required UpdateTime is a string version of the967230863 = Fri Aug 25 time_t of the last time that a change 15:14:262000 was made in the shared memory table of registered elements. e =NumberOfEntries Required The number of registered elements in “14” isthe number of the table, not the total number of registered elements.entries in the table. i = HostIpAddr Required The address of the hostwhere the server is located p = Port Optional (can In network byteorder, the port of the “20550” normalized is be Required) sending DNSserver. 18000.

If the server receiving the heartbeat message has the same number ofentries, the time from the update field and the network address of thesending server are recorded in a table. There is no acknowledgement orresponse to the heartbeat.

If a server receives a message with a different number of currentregistrations, the host with the less recent (older) update time sends asession request message with its count to the host with the more recentupdate time. Only one update session is allowed at a time. Once the hostwith the smaller number receives a session header message from a host,any other session header message is rejected. An example of a sessionrequest message is the following:

o=967230863;i=10.4.1.18;e=12;p=20550,

with the fields described in Table 10.

TABLE 10 Session Header Message Fields Field Required Comments From theExample o = SessionId Required SessionId is a string 967230863 = Fri Aug25 version of the time_t of 15:14:26 2000 the time that the sessionrequest was sent. i = HostIpAddr Required In IPv4 dot notation. e =NumberOfEntries Required The number of registered “12” is the number ofelements in the table, not registered elements. Note the total number ofentries that in the example in the table. heartbeat above there were 14entries. p = Port Optional (can be Required) In network byte order, the“20550” normalized is port of the sending DNS 18000. server.

If the server that receives the session message is able to start anupdate session, an acceptance message is returned that echoes back thesession open request and reports that the server is ready to begin thesession. The message looks like this:

k=ACK;o=967230863;i=10.4.1.18;e=12;p=20550

If the server that receives this message is already in session, or theUNIX fork function call fails, the server rejects the session by amessage in the following format that follows to the sending server:

k=NAK;o=967230863;i=10.4.1.18;e=12;p=20550,

with the fields described in Table 11.

TABLE 11 Session Reject Fields From the Field Required Comments Examplek = ACK or k = NAK|reason ACK or NAK is required, the reason is optionalo = SessionId From the request i = HostIpAddr From the request e =NumberOfEntries From the request p = Port From the request

An acceptance (k=ACK) message is followed immediately by the start oftransmission header message. The message is in the following format:

x=STX;o=967230863;i=10.4.1.18;e=14;p=20550,

with the fields described in Table 12.

TABLE 12 Acceptance Message Fields Field Required Comments From theExample x = STX Required o = SessionId From the request i = HostIpAddrRequired The address of the sending server, in IPv4 dot notation. e =NumberOfEntries Required The number of registered elements in the tableon the sending server, not the number of entries in the session request.p = Port Optional (can be Required) In network byte order, the “20550”normalized is port of the sending DNS 18000. server.

Then the sending server sends a copy of each registration to thereceiving host:

r=ST4;e=14; h=cpci_(—)1.techcontrol.com;i=10.4.1.32;p=20806;o=967230863

The fields in the registration message are described in Table 13.

TABLE 13 Registration Message Fields Field Required Comments From theExample r = ElementName Required ElementName can be a “ST4” is short formaximum of 31 bytes. “State4.” There is enough room to be clear aboutthe name, as in “ST_Alerting.” e = NumberOfEntries Required The numberof entries on the sender at the time this message was sent (up to datein real time). h = Hostname Optional Maximum size of NI_MAXHOST-1(1023). i = HostTCPaddress Required In IPv4 dot notation. p = portRequired In network byte order “20806” is how the network byte order for18001 is reported by Linux on Intel x86's. o = sessionId Required Fromthe original session request

The receiving server can interrupt the flow when the counts are equal,as follows:

k=CAN;o=967230863;i=10.4.1.18;e=12;p=20550

with the fields described in Table 14.

TABLE 14 Interrupt Message Fields From the Field Required CommentsExample k = CAN Required o—SessionID Required From the request i =HostIpAddr Optional The address of the sending server, in IPv4 dotnotation. e = NumberOfEntries Required The number of entries on thesender at the time this message was sent (up to date in real time). p =Port Required In network byte order, the port of the sending DNS server.

The data stored by the sleedns server is preferably kept in sharedmemory so that it can survive the collapse and restart of the serverprocess.

The SLEE DNS Server makes two clones of itself at initialization time bycalling the UNIX system function fork. The original executable and eachof the forked processes is referred to as a thread. The main thread isthe original executable that is launched by the operating system and isresponsible for: (1) initializing what has to be present in all threads,(2) forking the two child tasks, (3) receiving all messages over the UDPsocket, (4) processing registrations, deregistration requests, andqueries, (5) multicasting the synchronization messages to other servers,and (6) setting the cancellation flag to end a session for the downloadsession thread.

The heartbeat thread is in a constant loop that waits for the amount oftime in the configuration file, and then multicasts the heartbeatmessage.

The count rectification session thread sends a copy of each registrationentry to the server that requested to see all the registrations. Itsloop is controlled by the cancellation flag that may be set by the mainthread.

The state machine that governs the receiving end of the countrectification is shown in Table 15.

TABLE 15 Receiving State Machine State Event Next State Idle Socketinitialization succeeds Invite Socket initialization fails Idle InviteFailure to send (3 times) Invite Failure to send #4 Clean Wait ACKReceive ACK from sender Wait STX NAK from sender Clean Timeout (3 times)Wait ACK Timeout #4 Clean Wait STX STX from sender Recv Timeout (3times) Invite Timeout #4 Clean Recv Next registration EvaluateEvaluation OK Recv NAK to correction Clean ACK to correction Recv ETXfrom sender Clean Evaluate Record matched Recv Record not matched andadded makes Cancel counts equal Record shows more recent state hereCorrect Cancel Send OK Clean Failure to send (3 times) Cancel Failure #4Clean Correct Sent NAK to sender Recv Failure to send (3 times) CorrectFailure to send #4 Clean Clean Clean complete Idle

The state machine for sending instances of sleedns is shown in Table 16.

TABLE 16 Sending State Machine State Event New State Idle Invitationfrom receiver Send ACK Send ACK Failure to send (3 times) Send ACKInvitation from receiver Reject Failure #4 Clean Send OK Send STX SendSTX Send failure (3 times) Send STX Invitation from receiver RejectFailure #4 Clean Send OK Send Regs Send Regs Send failure (3 times) SendRegs Invitation from receiver Reject Failure #4 Clean NAK from receiverEvaluate Send OK Next Record Evaluate Accept change; send ACK Send RegsInvitation from receiver Reject Reject change; send NAK Send Regs Sendfailure (3 times) Evaluate Failure #4 Clean Next Record Exists Send RegsInvitation from receiver Reject No record Send ETX Send ETX Send failure(3 times) Send ETX Invitation from receiver Reject Send failure #4 CleanSend OK Clean Reject Send NAK to receiver Clean Invitation from receiverReject Clean Clean up complete Idle Invitation from receiver Reject

The SLEE DNS servers provide the advantage of allowing for a softwarearchitecture that is infinitely scalable and fully distributed.Referring to FIG. 9, Node A 160 a includes call control and devicecontrol 162, and a finite state machine 164 that controls theapplication. Above the finite state machine are the DNS libraries 166that allow access to the States 168 a, 168 b, 168 c and SIBs 170 a, 170b, 170 c that are distributed across the network. The DNS servers 172 a(on Node A 160 a), 172 b (on Node B 160 b), 172 c (on Node C 160 c) keepeach other synchronized so that the server 172 a on Node A is aware ofthe existence of the States 168 b, 168 c and SIBs 170 b, 170 c on theother nodes. The messaging libraries allow the application on Node A toexecute States and SIBs on the other nodes, e.g., Nodes B and C. Theother nodes can be within the same network segment, on different networksegments, or even on different continents.

SLEE Library

Rather than forcing the application to learn the details of using theSLEE DNS server, the sleelib, a group of library functions, is providedto make the interface relatively clean and easy. The library ispreferably written in C. Applications and application elements that usethe library include specific headers files and link sleelib.o into theirprograms.

The library assumes the use of IP4 multicasting between network nodes sothat new nodes can come on the network without being specifically knownto the UNIX network configuration files. Preferably, the sleedns andsleeport modules are running on the local computer in order to permitthe library to function properly.

Referring now to FIG. 10, the three basic application elements that thelibrary accommodates are shown: a finite state machine (FSM) 180, astate process 182, and a SIB 184. The finite state machine 180 is on theleft with sleelib 186 linked in. The notation “FSMz” means “some (z)finite state machine”. The state process 182 is in the middle withsleelib 186 linked in. The notation “StateN” means “some (N) state”. TheSIB is on the right with sleelib 186 linked in. The notation “SIBx”means “some (x) SIB”. It is noted that the finite state machine 180, thestate process 182, and the SIB 184 are each independent processes ratherthan threads.

The FSM 180 calls sleeInit during its initialization phase. After that,the FSM 180 performs whatever processing is required. When a transitionoccurs from one state to another, the FSM 180 sends a message to thestate 182 that should do the processing by calling sleeSend. The FSM isfree to continue processing while waiting for a response, or it canimmediately call sleeRecv to block for a response. A loop is provided inthe FSM that will lead from the bottom to the top. It is, of course, notnecessary for the application on the left to be a finite state machine.

The state 182 calls sleeInit during its initialization phase. Althoughit is typical for the state to do little processing before waiting forinput from the FSM (or some other application), it is available forprocessing. Eventually, the state waits for input from some other sourceby calling sleeRecv. When the input arrives, the state 182 processes theinput as required. Eventually, the state calls sleeReply to sendsynchronizing information back to the FSM that sent the input. In theexample shown in the FIG. 10, the state makes a call to SIB for someprocessing. The sending of the data is accomplished by callingsleeSubmit, and the response is read by calling sleeRead. It is notnecessary for every state to call another application element (SIB).FIG. 10 merely illustrates that there is a secondary method to send datato another entity and a mechanism to receive an expected reply that willnot be interleaved with other forms of input.

The SIB 184 process is substantially a replica of the state process 182,except it is simplified. The SIB calls sleeInit during itsinitialization phase. After that, the SIB receives input by callingsleeRecv, and it sends responses back to the sender by callingsleeReply.

For the FSM 180, the standard flow is sleeInit, sleeSend, sleeRecv. Forthe state 182, the standard flow is sleeInit, sleeRecv, optional callsto sleeSubmit and sleeRead, and then sleeReply. The state may then sendto another state or to another SIB for additional processing. For theSIB 184, the standard flow is sleeInit, sleeRecv, sleeReply. The SIB mayuse sleeSubmit and sleeRead to send data to another state or another SIBfor processing. Neither the state nor the SIB must reply. Of course, ifthe sender of the input is blocked on a reply, the state or the SIBcould leave a process blocked on a sleeRecv or sleeRead forever. Theeffects on the robustness of the system are easy to predict. If the FSMhas all of its states contained within itself, there is no need to callsleeInit, sleeSend, or sleeRecv. A similar statement hold true for thestate and the SIB. Note that the FSM, the state, and the SIB are not“aware” that there is UDP messaging that leaves the elements looselycoupled. The FSM, the state, and the SIB could each be located on adifferent computer, and there are no geographical boundaries on thedata. It is not necessary for what is shown as a finite state machine tobe a finite state machine. Any type of application will do. It is notnecessary for the state process to implement a “state” for a finitestate machine. It is not necessary for the SIB to be in the picture. Theillustration means to show a typical usage.

The sleeInit function initializes the SLEE DNS environment on behalf ofan application. The function binds two UDP sockets for listening, andcreates a UDP socket for communicating with the SLEE DNS server.

The sleeSend function sends the contents of sendbuf to the processregistered as the “destination”. The sleeSend function keeps a table ofrecently used addresses so that it is not necessary to do a SLEE DNSlook up for each message. The sleeSend function sends sendlen bytes ofdata. The function will time out in some combination of seconds secondsand usec microseconds. If both seconds and usecs are zero, there will beno time out, and the function will block until the send will succeed orfail at the kernel level.

The sleeReply function provides a way for an application element toreturn data and/or control to the application element that sent thesleeReply function data for processing. A response can be receivedwithout interfering with the main sleeRecv/sleeReply loop.

Application elements that want to send to another application element(like a subroutine) call sleeSubmit and then receive a response bycalling sleeRead. The sleeSubmit function has the responsibility toquery the SLEE DNS to look up the host, IP address, and port for thenamed element, and to send the UDP message to that port on that host.The sleeSubmit function keeps a table of recently used addresses so thatit is not necessary to do a SLEE DNS look up for each message. ThesleeRead function reads for an incoming reply to a message previouslysent by calling sleeSubmit.

The call processing language (CPL) of the SLEE implements EO/AT Class 5services on the SX. Each conventional Class 5 feature is dissected intoa sequence of atomic functions. Analysis of Class 5 services is used tocreate a transition table which maps each transition in a call sequenceto a basic (or atomic) function (SIB) that performs a specific featureinteraction. The call processing language (CPL) then generates a callstate transition table, which is implemented in the SX BCP function.Upon initialization, the BCP loads the call state transition table intomemory and uses it to determine which, if any, SIB gets called duringcall processing when a call transitions into a new state (e.g.,idle/null to off-hook).

The overall control of the execution of the SIBs resides within clearlydefined finite state machines (FSMs) which, similar to the call statetransition tables, are generated by the CPL and loaded into the SX BCP.The FSMs for the originating and terminating sides of a call are definedby the ITU, as follows.

When the calling party initiates a call, the SX BCP, which emulates anEO/AT switching exchange, starts the originating basic call state model(O-BCSM) process. The O-BCSM models the caller lifting the receiver,dialing a number, and making a call. The O-BCSM states are enumerated asfollows:

-   -   O_Null: call does not exist    -   Auth_Orig_Attempt: detects that someone wishes to make a call    -   Collect_Info: dialing string is collected from the dialing party    -   Analyze_Info: complete string is translated into a routing        address    -   Select_Route: actual physical route is selected    -   Auth_Call_Setup: relevant call type restrictions are examined    -   Send Call: control of the call is transferred to the terminating        basic call state model (T_BCSM) object    -   O_Alerting: waiting for called party to answer    -   O_Active: active conversation    -   O_Disconnect: a disconnect message is received from the T_BCSM    -   O_Suspended: a suspend indication is received from the T_BCSM    -   O_Reanswer: party picks up receiver after placing it down        momentarily    -   O_Exception: cleanup, line releases, appropriate messages.    -   O_MidCall: signaling action by calling party (hook flash);        interruption    -   O_Abandon: calling party hangs up before the call becomes active

The terminating basic call state model (T-BCSM) models the called partyreceiving a call. The T-BCSM states are enumerated as follows:

-   -   T_Null: call does not exist    -   Authorize_Termination_Attempt: call is verified if to be passed        to the terminating party    -   Select_Facility: terminating resource is selected    -   Present_Call: call is presented    -   T_Alerting: called party is alerted via ringing (timed activity)    -   T_Active: call enters active state    -   T_Disconnects: called party disconnects    -   T_Exception: cleanup, line releases, appropriate messages    -   T_MidCall: signaling action by called party (hook flash);        interruption.    -   T_Abandon: abandon message from O_BCSM.

Referring to FIG. 11, in order to emulate EO/AT stored program switchingfunctions and process a high volume of calls within tight delayconstraints, the call states and the events that cause transitionsbetween them need to be made available to the SLEE 34. In addition, thecall finite state machines are located close to the persistent calldata, which resides within the domain of the SX 14. A tight couplingbetween the SLEE 34 and the SX connection control domain is made in thebasic call process function (BCP) 20. The BCP 20 loads the call finitestate machines (O-BCSM 190 and T-BCSM 192) and respective transitiontables 194, 196 into memory and uses them to perform call control anddetermine which SIB 198 a, 198 b, 198 c, . . . , 190 a, 190 b, 190 c, .. . , if any, gets called when a call transitions into a new state. Eachstate has at least two outcomes, success and failure. The outcometriggers the process to the next state.

The protocol for data interaction between the SLEE state module and thefinite state machines is as follows:

Total Number of Records Within Packet Data ID₁ Length of Data Field₁Data Field Description₁ Payload₁ . . . . . . . . . . . . Data ID_(n)Length of Data Field_(n) Data Field Description_(n) Payload_(n)

The data types of the above fields are defined to be ANSI C data typesand are listed below:

Data ID char Length of Data Field char Data Field Description charPayload as described in Tables 17 and 18.

TABLE 17 Input Data Field Definitions Data Description Data ID DataLength (enums) Payload 1 (int) sizeof(int) what int is it? value of int2 (bool) sizeof(int) what bool is it? 1 or 0 3 (char) sizeof(char) whatchar? Value 4 (string) strlen( ) + 1 what string? Value + NULL 5 (bitfield) 64 bits which Binary (subscriber/ channel) 6 (prev or currentstate) sizeof(int) NULL Value 7 (event that happened) sizeof(int) NULLValue

TABLE 18 Output Data Field Definitions Data Description Data ID DataLength (enums) Payload  1 (int) sizeof(int) what int is it? value of int 2 (bool) sizeof(int) what bool is it? 1 or 0  3 (char) sizeof(char)what char? Value  4 (string) strlen( ) + 1 what string? Value + NULL  5(bit field) 64 bits which (subscriber/channel) Binary 11 (set subscriberint) sizeof(int) which field Value of int 12 (set subscriber bool)sizeof(bool) which field 1 or 0 13 (set subscriber char) sizeof(char)which field Value 21 (set channel int) sizeof(value) which field Value22 (set channel bool) sizeof(int) which field 1 or 0 23 (set channelchar) sizeof(char) which field Value 3x sizzeof(int) Tone ID from enumvalue 4x sizeof(int) Timer Useconds 50 (set subscriber bit) 1 which bitfield 1 or 0 51 (set channel bit) 1 which bit field 1 or 0 5x (etc.) 60(set next state) sizeof(int) NULL Value 70 (generate indication)sizeof(int) indicate transition to/from value originating, terminating80 (active/passive call leg) sizeof(char) which call leg are we on?Value (0/1)

An initialization function, sleeParmsInitO, allows the initialization ofthe buffer that will be used to send the packet data. The functions thatare used to assemble and disassemble the UDP packets are sleeParmsAddOand sleeParmsGetO, respectively. In order to release any buffers thatmay be dynamically allocated within the course of usage of the aboveroutines, a clean up routine has also been implemented calledsleeParmCleanO. These functions do not send or receive any data, butrather are data placeholders permitting other routines ready access tothe packet information. The functions are made available to both thefinite state machine (FSM) as well as directly within the SLEE and aredesigned to be re-entrant capable.

sleeParmsInitO

The buffer that will be used to hold the packet being built will beinitialized in this routine. The entire buffer will be initialized tonull characters for the sake of simplicity. The record counter that iskept to track the number of records being added to the buffer is alsoinitialized as well as all pointers that are being used within the SLEEParameter functions.

sleeParmsAddO

This function is used to assemble information that needs to becommunicated to other processes. This assembly is callable multipletimes so that multiple records can be added to a send buffer used tohold all of the packet data. The number of records added to the packetare kept track of so that the number may be added to the top of the sendbuffer. The function also contains standard error checking to validateinformation coming into the function and to send back the appropriatereturn values for the calling routine to evaluate.

sleeParmsGetO

This function is used to dissect all of the information within the UDPpacket that has already been received and returns the information to thecalling routine one record at a time. Each subsequent call to thefunction returns the next record available within the packet. This isdone through the parameter list of the function. The function alsocontains standard error checking to validate the integrity of the packetbeing dissected and to send back the appropriate return values for thecalling routine to evaluate.

sleeParmsCleanO

This function cleans up all the sleeParm functions described above. Thefunction is placed in the function sleeCleanO (SLEE Library) and isresponsible for the freeing of allocated memory and all other generalclean-up that may be needed.

From the foregoing, it will be appreciated that the SLEE can operate intwo modes: Mode 1, Loosely Coupled SLEE, or Mode 2, Tightly CoupledSLEE. From the perspective of a single softswitch, it is possible toimplement one SLEE operating in Mode 2 and one or more SLEEs operatingin Mode 1. Furthermore, from a network perspective it is possible toimplement a plurality of SLEE in either mode of operation.

When describing applications for the Decoupled TelecommunicationsSystem, there are two broad classifications, Network Applications andUser Applications. An example of a Network application is broadbandaccess. Broadband access is a superset of functionalities that embodyall of the essential capabilities of a Class 5 SPCS (EO/AT) in the PSTNsuch that the User cannot distinguish between their Class 5 servicedelivered through a Decoupled Telecommunications System versus a Class 5SPCS in the PSTN.

To achieve functional equivalence to the Class 5 SPCS in a DecoupledTelecommunications System, an equivalent state machine is createdthrough the SLEE CPL and then mobilized into the softswitch. This statemachine combines the Originating and Terminating basic call statemachines specified by the ITU for Capability Set 2. The SLEE functionwhich implements this composite state machine is the Basic Call Process(BCP). The BCP is a specialized implementation of the ApplicationServices Interworking Layer. The BCP is a byproduct of the SLEEoperating in mode 2. The BCP function facilitates tightly coupledinteraction between the SLEE and the softswitch. The BCP is the‘gearbox’, subject to the previous analogy. SLEE mode 2 is theappropriate operational mode for the broadband access networkapplication because it incorporates user services which are subject tothe ‘delay budget’.

An example of a User application is Unified Messaging (UM). Although UMis a relatively complex application, it mainly involves repeatedrequest/response pairs of user interactions where moderate delays areacceptable. SLEE mode 1 is the appropriate operational mode for the UMapplication because the delay budget is not an issue and the applicationgenerally involves lengthy interactive sessions between the SLEE andother distributed Application Server elements including media servers,messaging servers and web servers using protocols that are not typicallysupported in a softswitch.

There have been described and illustrated herein an embodiments ofmethods and systems for providing integration between PSTN and IPnetworks. While particular embodiments of the invention have beendescribed, it is not intended that the invention be limited thereto, asit is intended that the invention be as broad in scope as the art willallow and that the specification be read likewise. Thus, whileparticular files, modules, threads, parameters, etc. have been disclosedby name and with a particular implementation, it will be appreciatedthat other files, modules, threads, parameters, etc., with differentnames and implemented in different manner, yet provide the samefunctionality, may be used as well. In addition, while particularelements have been described as preferably being implemented in hardwareand other in software, it will be appreciated that hardware elements maybe implemented in software and software elements may be implemented inhardware. Most significantly, while the invention has been describedwith respect to an IP network, it will be appreciated that virtually anypacket network may be used in lieu of an IP network. It will thereforebe appreciated by those skilled in the art that yet other modificationscould be made to the provided invention without deviating from itsspirit and scope as claimed.

1. In a telecommunications network linking a PSTN and a packet network,a service level executable environment comprising: a) a scriptinglanguage; b) a compiler means for compiling scripts written with saidscripting language into executables; c) a plurality of dynamicallyloaded shared libraries, wherein said plurality of dynamically loadedshared libraries are distributed over the packet network and anexecutable at a first location can utilize at least two dynamicallyloaded shared libraries from second and third different locations in thepacket network, and at least two executables run at least partly inparallel.
 2. A service level executable environment according to claim1, further comprising: d) a domain name server, wherein said pluralityof dynamically loaded shared libraries are located by said domain nameserver.
 3. A service level executable environment according to claim 1,wherein: said dynamically loaded shared libraries include a plurality ofsystem independent building blocks.
 4. A service level executableenvironment according to claim 1, wherein: said scripting languagepermits one executable to cause another executable to be executed.
 5. Aservice level executable environment according to claim 1, furthercomprising: d) a plurality of executables located at different locationsin the packet network.
 6. A service level executable environmentaccording to claim 5, wherein: one of said executables at one locationin the packet network includes means for causing another of saidexecutables at another location in the packet network to be executed. 7.A method for distributing call service functions over a packet networklinked to a PSTN: a) distributing a plurality of dynamically loadedshared libraries over the packet network; b) using a scripting languageto write telecommunication function scripts which call dynamicallyloaded shared libraries from different locations on the packet network;c) compiling the scripts into executables, which, when executed, createcall service functions; and d) executing at a first location at leasttwo executables from second and third locations in the packet network atleast partly in parallel.
 8. (canceled)
 9. (canceled)
 10. (canceled) 11.(canceled)
 12. A method for distributing call service functionsaccording to claim 7, wherein: said call service functions includefunctions selected from the group consisting of caller-ID, call waiting,and three-way calling.